Cft Sc Mdt Pdt Ps Cal Cft /

The DØ Level 2 (L2)trigger is a subsystem of the overall DØ trigger [1] which has the responsibility of reducing the event rate from 10 KHz to 1 KHz, while introducing less than 5% deadtime. The system is organized as a number of preprocessors and a global processor. Each preprocessor digests information from a single detector system and produces a condensed list of the objects. The global processor receives the object lists, matches across detectors, and applies selection criteria to the objects. The front end system contains buffers to hold 16 events awaiting L2 decisions. The preprocessors are implemented as either arrays of DSP’s or fast serial processors; the global processor is a fast serial processor, a Dec Alpha 21164 of 500 MHz (or better) on a VME board with a 128 bit input bus. The board is evolved from a commercial PCI-based PC card design. The overall L2 design has been guided by extensive queuing simulations. I. CONSTRAINTS, SIMULATIONS, AND ARCHITECTURE CHOICES The Run II DØ Level 2 (L2) triggering system [2] requirements are to provide a factor of 10 in rejection while maintaining electron, muon and jet efficiency of the Run I Level 3 (L3) software trigger [3], with a deadtime of less than 5% at 10KHz input rate. In addition, the system will tag events passing one or more of 128 selection criteria (with conditions defined in an ASCII trigger definition file), a level of potential complexity also comparable with the L3 trigger from the first run. Several constraints were imposed by design choices made before specification of L2. The front end data buffering system requires that trigger decisions be available in the same order as events passed by the L1 trigger, and imposed a maximum of 16 events in the L2 system awaiting trigger decisions (beyond 16 generates deadtime). Reuse of the VME drivers for sending events to L3 for final readout also limited the use of the VME bus for other purposes. As the drivers do not relinquish mastership during event transfer, time-critical communication cannot use VME in crates containing these drivers. The basic parameters indicate that decisions are required on average every 100 sec. We performed extensive queuing simulations [4] before choosing an architecture for the system. The chief simulation tool was RESQ [5], which incorporates a mixture of queuing theory and direct simulation. The chief results were checked in simple cases by Fortran programs We would like to acknowledge the support of the National Science Foundation. and using results from queuing theory for simple subsystems [6]. To minimize the I/O connections, it was early decided to restrict specialized preprocessing of detector information to preprocessors. For combining information across detectors, a farm architecture was considered, but was found to generate enormous deadtime in spite of what appeared to be adequate capacity, because of the requirement that decisions be announced in the order of arrival of events. All farm nodes would be idled when an event requiring a long processing time appeared: most nodes would be left holding events whose fate had been decided, but which could not be announced until a decision was reached on a previous event. Instead, a single faster global processor with a FIFO for holding events for decisions was chosen. The final architecture can be thought of as a stochastic pipeline of two steps: preprocessing each detector’s data in parallel, and combining the high-level information in a second global stage. Each stage has a nominal time budget of 100 sec; the simulations give low deadtime for processing times in the 50 75 sec for processors and global alike. It is critical that the preprocessors not be restricted to event-synchronous operation, lest the processing time distribution in the preprocessors resemble a long-tailed “worst of n” distribution. Sensitivity analysis also indicated the importance of minimizing variation of decision time from event to event (thus imitating a true pipeline), and the importance of providing the maximum number of buffers (16) in front of each transfer point in the system. This simplifies data flow control in L2, allowing any busy signals to be generated by the front end, allows design of each data transfer in confidence that there is always a place ready to receive the data, and allows the system itself to decide where buffers are needed. However, one must then monitor the buffer utilization in each location to understand the dynamics of the system under load. II. GLOBAL PROCESSOR As shown in Figure 1, preprocessors are foreseen for electromagnetic clustering, jet finding, track sorting, preshower hit finding, and muon tracking. We will discuss in detail the global processor, the calorimeter preprocessors, and the muon subsystems as their designs are further advanced. A. Alpha in VME Card The difficulty of the task of the global processor depends on the amount of data it receives and the complexity of analysis to be performed on the data. Our current estimates call for .5KB of information to be provided by preprocessors on an average L2: Combines objects into e, μ, j CAL